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(54) Title: CONTROL OF DATA ACCESS BY DYNAMICALLY VERIFYING LEGAL REFERENCES 

^ (54) Titre : CONTROLE D'ACCES AUX DONNEES PAR VERIFICATION DYNAMIQUE DES REFERENCES LICITES 

(57) Abstract: The inventive method for controlling access to data which is used by reference in a program execution system (in- 
eluding processes and aims) during the program execution consists in memorising by the system the totality of references obtainable 
by said program with the aid of means considered legal, before any operation which can be prohibited if it relates to values which 
are not legal references, in verifying by the system whether said values are amongst the legal references memorised for the program 
and in accepting or rejecting the operation, respectively. 

(57) Abrege : Procede de controle d'acces a des donnees manipulees par references dans un systeme d' execution de programmes (y 
compris processus et taches), comprenant, lors de I'execution d'un programme, les etapes suivantes: - la memorisation par le systeme 
de I'ensemble des references qu'obtient le programme par des moyens consideres comme licites ; - avant toute operation que Ton veut 
interdire si elle porte sur des valeurs qui ne sont pas des references licites, la verification par le systeme que ces valeurs sont parmi 
les references licites que Ton a memorisees pour ce programme, et I'acceptation ou le rejet de I'operation en consequence. 
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5 CONTROLE ACCES AUX DONNEES PAR VERIFICATION 

DYNAMIOUE PES REFERENCES LICITES, 



10 La presente invention conceme un precede pour le controle d'acces a des 
donnees manipulees par des references dans un systeme informatique securise. 

On sait qu'une des caracteristiques principales des syst^mes informatiques 
s6curis6s, qu'ils soient distribues ou non, est le controle d'accds aux ressources 
15 logicielles du systeme, et notamment aux programmes et aux donndes. En 
particulier, lorsque plusieurs programmes s'executent simultanement (ou 
altemativement) dans le systeme, on veut s'assurer que Texecution de Tun 
n'affecte pas Texecution des autres, ni celle du systeme : ils sont isoles. 

20 Plus g^n^ralement, on pent laisser certains programmes interagir entre eux, 
mais uniquement dans le cadre d'une politique stricte de partage contr616 des 
donnees. On se protege ainsi non seulement de la propagation d'erreurs 
involontaires de programmation, mais aussi et surtout d'actions malveillantes 
(aussi appel^s « attaques ») qui visent a alterer le bon fonctionnement du 

25 systdme et des programmes ou h devoiler des informations confidentielles. 

Par programme, Ton entend ici non seulement le code executable, c'est-a-dire 
une suite d'instructions, mais aussi le processus (ou tache), c'est-a-dire le code 
en cours d'execution, avec son environnement specifique constitue des 
30 donn6es qui lui sont propres ainsi que des ressources qui lui sont attribuees. 
Par donn6es Ton entend aussi bien des valeurs manipulees par un programme 
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que les zones de memoire oil sont rangees des valeurs. Selon les systemes 
(systemes d' exploitation, environnements d'ex^cution, machines virtuelles, 
etc.), les donnees appartiennent au programme qui les a ct66s ou, plus 
generalementj, a un groupe de programmes qui disposent de droits d'acces sur 
5 ces donnees. Ces droits peuvent etre donnes a d'autres programmes pour des 
operations particulieres choisies; de telles donnees sont dites partageables. 

Par exemple, dans le langage «Java Card» (marque d^posee de Sun 
Microsystems), les programmes sont organises en « packages » (paquetages) a 

10 rinterieur desquels le partage de donnees (objets et tableaux) est libre. En 
revanche, Tacces a des donnees qui appartiennent a un autre « package » est 
limite par deux dispositifs : un mecanisme de demande d'acces et un 
mecanisme de pare-feu (« firewall »). En effet, pour acceder a une donn^e 
dont on n'est pas proprietaire, il faut en faire la demande au « package » qui en 

15 est proprietaire, demande qu'il peut accepter ou refuser. Par ailleurs, le pare- 
feu filtre toutes les operations que Ton peut faire sur une donnee, quel que soit 
le moyen par lequel on se Test procuree. En particulier, toute operation de 
lecture ou d'ecriture sur un objet d'un autre « package » est interdite, sauf pour 
appeler une m^thode (routine de programme) explicitement declar6e par ce 

20 « package » comme partageable. II existe 6galement des objets du systeme 
(c'est-a-dire de Tenvironnement d'ex6cution «Java Card Runtime 
Environment »5 ou JCRE) qui sont accessibles (sans droits d'acces 
particuliers) par tout programme. 

25 Les donnees d'un programme, et en particulier les donnees complexes 
(structures, objets, tableaux, etc.) sont generalement identifiees par une 
ref6rence. C'est par Tintermediaire d'une reference que la donnee associee, 
ainsi que les composants de cette donnee (champs de structures et d' objets, 
Elements de tableaux, methodes, etc.), peuvent 6tre manipules, c'est-^-dire lus, 

30 Merits, appel6s. La reference elle-meme peut 8tre m6morisee, regue et 
transmise. 
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Une reference est souvent un pointeur ou un « handle ». Un pointeur est 
Tadresse ou se trouve rangee une donnee dans la memoire. Un « handle » est 
un index dans une table de pointeurs (ou plus generalement dans urie table de 
5 references). Les valeurs des pomteurs et « handles » comportent aussi parfois 
des bits specifiques qui donnent des informations sur la donnee (par exemple 
sur la zone memoire referencee ou sur Tinformation s'y trouvant) ou, dans le 
cas de « handles », sur la table associee. 



10 Trois attributs majeurs concement la « correction » des references : 

- Une reference peut etre valide ou invalide. Une reference valide est 

une reference associee effectivement a une donnee d'un programme. 

Une reference invalide est une valeur stock^e ou exploit^e en tant 

que reference mais qui n'est pas associee a une donnee. Par exemple, 
15 dans le langage C, un pointeur vers une structure de donnee est 

valide ; en revanche, un pointeur vers T element d'un tableau a 

I'indice -1 est invalide. La validite d'une reference est intrinseque ; 

elle ne depend pas P agent (programme, processus, tache, etc.) qui la 

manipule. 

20 - Une reference peut aussi etre licite ou illicite, pour un agent donn6 

du systeme. Une reference licite est une reference qui a 6t6 obtenue 
par des moyens licites. Une reference illicite est une reference n'a 
pas ete obtenue par des moyens licites. La definition effective de ce 
qu'est ime reference licite ou illicite depend du systeme, du langage 

25 de programmation et eventuellement du contexte. Par exemple, en 

langage C, Tarithmetique de pointeur (fabrication d'un pointeur par 
addition d'lm pointeur et d'un entier) est licite ; elle est revanche 
illicite en « Java ». Une reference n'est pas intrinsequement licite ou 
illicite : c'est une propriete specifique a un agent, qui depend de la 

30 maniere dont la reference a 6t6 obtenue par cet agent. 
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- Une reference peut egalement etre « dereferen9able » ou 
« ind6r6feren9able » par un agent donne. Une reference 
dereferen9able par un agent est tme reference vers une donnee pour 
laquelle T agent a des droits d'acces. Une reference ind6referen9able 
5 par un agent est une reference vers une donnee pour laquelle T agent 

n'a pas de droits d'acces. Par exemple, en « Java Card », une applet 
qui detient une reference vers un objet peut acceder a un champ de 
cet objet (ou element, dans le cas ot 1' objet est im tableau) a la 
condition que I'objet appartienne au mdme package (paquetage) que 

10 cette applet. En revaache, si I'objet appartient h un autre package 

(different egalement du JCRE), toute tentative d'acces est stoppee 
par un mecanisme de pare- feu et resulte en une levee d' exception (de 
la classe « SecurityException »). Une reference n'est done pas 
intrinsequement d6r6f6ren9able ou indereferen9able : c'est une 

15 propriety sp^cifique k I'agent qui detient la r6f6rence et aux droits 

d'acces qu'il detient ou non sur la donnee referencee. 

II faut noter que ce sont la trois notions independantes. 

20 Ainsi, ime reference peut 6tre invalide et licite ; c'est par exemple le cas dans 
un langage comme C quand on accede aux elements d'un tableau par 
arithmetique de pointeur et lorsque Ton depasse les limites du tableau. Une 
reference peut aussi etre valide et illicite : c'est par exemple le cas de 
references fabriquees a partir de references connues, dans le cadre d'une 

25 attaque, pour acceder a des donnees protegees auxquelles on ne devrait pas 
avoir acces. Enfin, une reference peut egalement etre a la fois invalide et 
illicite ; c'est par exemple le cas de references fabriquees dans le cadre d'une 
attaque pour ecraser les donnees du programme par balayage systematique et 
« aveugle » de la memoire. 

30 
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Par ailleurs, une reference peut etre dereferen9able ou non, qu'elle soit valide 
ou invalide, licite ou illicite. Ainsi, Tacces a ime zone m^moire protegee, que 
la reference soit valide ou non, peut etre controle par des droits. D'autre part, 
on peut obtenir par des moyens illicites une reference vers une donnee sur 
5 laquelle on a des droits d'acces ; on peut par exemple la fabriquer de toute 
piece au lieu de la demander au systeme. Inversement, on peut obtenir par des 
moyens licites une reference vers une donnee sur laquelle on n'a pas des droits 
d'acces, par exemple pour transmettre cette r6f6rence k un autre agent qui, lui, 
a les droits d'acces appropri6s. 

10 

L'invention a plus particulierement pour objet le controle des references 
illicites, les questions de validite et de « dereferen9abilite » pouvant etre 
trait^es par ailleurs k Paide de mecanismes qui sont propres k ces notions. 

15 De manidre gen^rale, Tacc^s k une donnee structur^e se fait en deux temps. II 
faut tout dabord obtenir une reference sur la donnee. On peut ensuite operer 
sur la donnee via sa reference, c'est-a-dire lire ou ecrire les composants 
(champs d'objet ou de structure, elements de tableau, etc.) de la donnee 
r6f6rencee, ou appeler une de ses routines. 

20 

II y a trois moyens principaux d'obtenir des references : 

- Un moyen licite de se procurer une reference est de Tobtenir du 
systeme ou d'un autre programme. Par exemple, en « Java » et en 

25 «Java Card», les references sont creees par le systeme lors de 

I'allocation de nouvelles zones de donnees en memoire. Ces 
references peuvent 6tre foumies et obtenues par un des moyens 
suivants : lecture et ecriture de champs publics d'objets ou de 
classes, arguments d'appels et valeur de retour de methodes, levee et 

30 rattrapage d'exceptions. En « Java Card », Tacces a un champ public 

d'lm objet appartenant k un autre « package » est toutefois interdit 
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par le pare-feu. Par ailleurs, ime reference a une donnee partageable 
appartenant au systdme ou ^ un autre « package » peut Stre 
demandee auprds du systeme. 

- On peut aussi fabriquer urie reference a partir d'une autre. Par 
5 exemple, dans le langage C, additionner ou soustraire un entier h un 

pointeur fabrique un nouveau pointeur. Le pointeur resultant est 
licite car Tarithmetique de pointeurs est licite, Mais il est valide ou 
non suivant la donn6e r^ferencee par le pointeur initial (pointeur a 
l'int6rieur d'un tableau ou d'une structure). Dans d'autres langages 
10 que C, le pointeur resultant peut ne pas 6tre licite. C'est le cas pour 

les langages « Java » et « Java Card », que ce soit au niveau du code 
source ou du code objet destine a T execution dans une machine 
viituelle. 

- Enfin, on peut aussi fabriquer xme r6f6rence de toute pi^ce. Un 
15 simple entier peut ainsi etre consid6r6 conrnie un pointeur ou un 

« handle » apres attribution d'un type reference. La r6f6rence 
resultante peut etre valide ou invalide. EUe est en revanche 
generalement consideree illicite, comme par exemple en « Java » et 
«Java Card». Une telle reference peut toutefois 6tre consideree 
20 comme licite dans des contextes et pour des langages particuliers. 

C'est le cas en langage C quand on accdde a des ports d' entree-sortie 
installes a des adresses memoires determinees. 



Auk deux temps de Facets a la donnee (obtenir une reference, puis operer sur 
25 la donnee associ^e via la reference) correspondent deux mesures couramment 
employees pour le contrdle d'accds : 

- D'une part, il faut empScher la contrefa9on de references. Autrement 
dit, un programme ne doit pas pouvoir fabriquer ime reference et 
pretendre Tavoir obtenue par des moyens licites. Comme indique ci- 
30 dessus, le sens de «moyen licite » varie selon les systemes, les 

contextes, et les langages de programmation utilises. Par exemple, a 
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la difference du langage C qui permet d'effectuer des operations 
arithmetiques sur les pointeurs, les langages «Java» et «Java 
Card » ont un syst^me de typage des donnees qui ne permet pas 
d'effectuer des operations sur des references ni d'en fabriquer de 

5 nouvelles de toute pidce. Les seules references dont un programme 

peut legitimement disposer en « Java » ou « Java Card » sont celles 
que lui a foumi le systeme (y compris la machine virtuelle) ou un 
autre programme, et qu'il a eventuellement memoris6es. La 
contrefa9on de references est done fonctionnellement impossible 

10 avec des programmes bien types. La contrefa9on est toutefois 

possible au niveau d'une machine virtuelle « Java » ou « Java Card » 
si elle n'effectue pas de verification de type, qu'elle soit statique ou 
dynamique (voir ci-dessous). Meme en cas de verification, il est 
toujours possible de creer des references illicites par injection de 

15 fautes au niveau materiel (bombardement ^lectronique, variations 

dans Talimentation electrique, etc.), par exemple dans le cadre d'une 
attaque contre une carte a puce. 
- D'autre part, le systeme doit filtrer toute operation sur les references. 
Autrement dit, le programme ne doit pas pouvoir effectuer 

20 directement une operation de lecture ou d'6criture sur des donnees 

referencees ; il doit passer par Tintermediaire du systeme, qui peut 
accepter ou refuser Toperation, en fonction du programme 
demandeur et des donnees referencees (notamment de leur 
proprietaire). Par exemple, a la difference des instructions du 

25 langage machine, qui permettent un accds direct et immediat k toute 

donn^e referencee, les instructions de la machine virtuelle « Java 
Card » (JCVM) verifient systematiquement des conditions de Taccds 
aux donnees avant de Taccepter ou de le refuser ; c'est le mecanisme 
de pare-feu du JCRE. Ce controle inclut egalement Tacces aux 

30 elements d'un tableau : le systeme verifie que Tindice des elements 
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auxquels on accede reste dans les limites licites, etant donnee la 
taille du tableau. 

Aucune de ces deux mesures, prise individuellement, ne suffit en general a 
5 securiser un systeme ; la securit6 repose sur leur combinaison. En fait, les 
types de protection offerts par chacune de ces deux mesures se recouvrent 
partiellement et se completent : 

- Ainsi, empScher la contrefa9on de references garantit qu'un 
programme ne manipule que des references licites. Cependant, 

10 Tacces a toutes les donnees correspondant k des references licites 

n'est pas pour autant autorise ; la presence additionnelle d'un pare- 
feu permet de restreindre les operations qu'un programme peut 
effectuer sur des references, qu*elles aient ete obtenues par des 
moyens licites ou non. 

15 - Toutefois, un pare-feu qui contrdle toutes les operations sur les 

references ne suffit pas k garantir la security d'une politique d'acces 
aux donnees : il peut etre trompe par des references contrefaites. 
C'est par exemple possible si Timplementation represente les 
references par des pointeurs directs vers des blocs memoire. En effet, 

20 dans ce modele, les descripteurs de donn6es (c'est-a-dire les 

informations de propri^taire, de classe, de type et de taille de tableau, 
utilisees lors de la verification du droit d'acces) sont stockes en 
memoire a des deplacements fixes par rapport aux pointeurs. II suffit 
a un programme malintentionne de contrefaire un pointeur au milieu 

25 d'un bloc de donnees, par exemple au milieu d'un tableau d'octets 

convenablement rempli, pour briser Tintegrite de la memoire : une 
telle attaque permet en effet de faire croire au systeme que la donnee 
associee au pointeur non seulement appartient au programme et est 
done accessible, mais aussi que la zone memoire de cette donnee est 

30 d'une etendue arbitrairement grande, ce qui permet de lire ou d'ecrire 

une cellule memoire quelconque. Ainsi, le contrdle des operations 
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sur les references n'interdit pas la fabrication et Tusage d'une 
reference qui n'a pas ete obtenue par des moyens licites ; un accds 
illicite k une donnee est done possible malgre le pare-feu. 

5 Le probleme de interdiction de la contrefafon de references est generalement 
resolu de deux manieres : par une verification statique reposant sur une 
analyse de programme ou par une verification dynamique des types de 
valeurs : 

- La verification statique par analyse de programme contrdle 

10 statiquement (une fois pour toute, avant toute execution) que le 

programme ne peut pas fabriquer lui-meme de references sur des 
donnees. Autrement dit^ une reference ne peut pas etre le resultat 
d'un calcul arbitraire du programme. Dans le cas d'un langage 
comme « Java » ou « Java Card », cette verification de type peut 

15 s'effectuer aussi bien au niveau d'un programme source 

(typiquementj a la compilation) qu*au niveau des programmes objets 
executables par une machine virtuelle (typiquement, lors du 
chargement du programme dans le systeme ou avant son execution), 
k I'aide d'lm verificateur de code octet (« bytecode verifier »). 

20 - La verification dynamique des types de valeur fait en sorte que les 

valeurs manipulees par le programme soient marquees par leur type 
(entier, reference, etc.). On verifie alors dynamiquement (lors de 
Texecution) que seules les valeurs marquees comme etant 
effectivement des references sont utilisees dans les operations qui 

25 portent sur des references. Le marquage n'est pas necessairement 

associ6 explicitement aux valeurs ; il peut porter sur les zones de 
stockage des valeurs et etre limits k uniquement certaines zones. Par 
exemple, dans le cas de la machine virtuelle « Java » ou « Java 
Card »5 il est suffisant de typer dynamiquement la pile d'operandes et 

30 les variables locales. En revanche, les valeurs stockees dans des 

tableaux, dans des champs statiques ou dans des champs d'instances 
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n'ont pas besoin d'etre explicitement marquees par leur type, car ce 
type pent dtre retrouve a partir d'autres informations (classe de 
Tobjet, type du tableau) disponibles par ailleurs. Cette approche, dite 
« pile typ6e », empSche la contrefa9on de pointeur car elle permet a 
5 la machine virtuelle de detecter et d'empScher toutes les tentatives de 

conversion d'un entier en reference, ainsi que les operations 
arithmetiques sur les references. Une valeur «Java» ou «Java 
Card » qui a le type reference est ainsi toujours une reference vers un 
bloc m^moire bien forme du systeme, contenant des informations 
10 correctes de proprietaire, de classe, et de taille. 



Ces solutions ne sont pas redondantes ou exclusives ; elles correspondent a des 
besoins ou a des moyens differents : 

- Ainsi, la verification statique par analyse de programme pent 6tre 
15 difficile a mettre en oeuvre dans des petits systemes embarques tels 

que les cartes k puce, qui disposent de peu de m^moire et dont la 
Vitesse d'execution est faible. Cependant, elle a Tavantage de signaler 
un probleme le plus tot possible. Un programme peut par exemple 
6tre rejete des son chargement dans le systdme. (La verification peut 
20 aussi avoir lieu en dehors du systdme d'execution et une signature 

infalsifiable Stre appos^e sur les progranmies valides.) 

- Pour sa part, la verification djaiamique des types de valeur a 
rinconvenient de consommer un peu de memoire (marque de type 
ajoutee aux valeurs ou a certaines zones de stockage) et surtout 

25 d'6tre coflteuse en temps d'execution (affectation et controle des 

marques). Cependant, elle a Tavantage d'etre robuste : si un 
programme a reussi a Stre charge dans le systeme, mSme par des 
moyens d^toumes, il ne pourra de toute fa9on pas effectuer 
^operations illicites. C'est aussi une garantie supplementaire contre 

30 des attaques materielles (par opposition aux attaques logicielles). Par 

exemple, m6me confinee dans une enceinte securisee, comme celle 
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d'une carte a puce, Texecution des programmes peut neamnoins etre 
perturbee en agissant sur le materiel (variations de Talimentation 
electrique, bombardement par des rayonnements, destructions de 
portes logiques, etc.). La verification dynamique est alors un moyen 
5 de controler regulierement, a chaque operation sensible, que la 

politique de contrSle dacces est bien respectee. 

Ces solutions, mises en oeuvre partiellement ou en totalite, peuvent etre 
combin6es afin de trouver les meilleurs compromis d'efficacite ou foumir la 
1 0 meilleure garantie possible. 

Une autre approche, qui ne resout que partiellement le probleme lie a la 
contrefa9on de references, consiste a verifier que toute valeur utilisee en tant 
que reference est efFectivement une reference connue du systeme. Cette 
15 verification dynamique de la validite des references n'interdit pas la fabrication 
de references. Cependant, elle interdit Tusage de references qui en fait n'en 
sont pas. En d'autres termes, seules les valeurs qui sont effectivement des 
references peuvent etre utilisees en tant que telles par le programme. 

20 La mise en oeuvre d'une verification dynamique de la validite des references 
depend fortement de la maniere de representer et de gerer les references dans 
le systeme. Par exemple, un gestionnaire de memoire, aupr^s de qui Ton peut 
demander la creation dune nouvelle zone de donnees ou bien sa liberation, sait 
exactement quelles references ont ete creees. II est done possible de savoir si 

25 un entier correspond ou non a xme reference valide existante. Dans le cas ou 
les references sont representees par des pointeurs, cette operation est toutefois 
couteuse car elle peut necessiter un large parcours des structures de donnees 
du gestionnaire de memoire. En revanche, si les references sont representees 
par des « handles », la verification est bien plus facile et surtout plus rapide : il 

30 suffit de verifier que rentier est inferieur ou egal a Tindice maximum de la 
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table de « handles » du gestionnaire de memoire, et que Tentree associee dans 
la table ne correspond pas a des donn^es qui ont ete liberees, 

Au meme titre que les deux verifications decrites ci-dessus (verification 
5 statique par analyse de programme et verification dynamique des types de 
valeur), la verification dynamique de la validite des references constitue une 
protection contre les attaques qui fabriquent des pointeurs vers de faux 
descripteurs de donnees (attaque decrite ci-dessus). En effet, ces pointeurs 
contrefaits ne sont pas reconnus par le systeme comme des references valides 

10 existantes et les operations d'acces sont d'emblee rejetees. Toutefois, ce type 
de verification ne garantit pas que le programme s'est procure par des moyens 
licites toutes les references qull utilise. Un agent pent notamment fabriquer et 
utiliser une reference valide et dereferen9able (reference vers une donnee sur 
laquelle il a des droits d'acces, par exemple une donnee partageable 

15 appartenant a un autre programme) sans qu'elle ait toutefois ete obtenue par 
des moyens licites. 

L' invention a done plus particulierement pour but de resoudre les problemes 
precedemment evoques. 

20 

Elle propose a cet effet une forme de verification dynamique qui porte sur la 
contrefafon de references et qui, d'une certaine maniere, complete la 
verification dynamique de la validite des references pour couvrir les cas 
d'utilisation de references illicites. 

25 

Conformement k T invention, cette verification dynamique des references 
licites consiste, au cours de Texecution d'un programme, a : 

- memoriser I'ensemble des references a des donnees qu'obtient le 
programme par des moyens licites, 
30 " verifier, avant toute operation que Ton veut interdire si elle porte sur 

une valeur qui n'est pas une reference licite, que cette valeur est 
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parmi les references licites que I'on a memorisees pour ce 
programme. 

Dans ce procede, les references pourront consister en des pointeurs ou des 
5 « handles ». 

Les moyens licites pour un programme d'obtenir des valeurs de reference 
pourront comprendre au moins Tune des operatioiis suivantes : 

- la lecture d'une variable ou d'une donnee appartenant au syst^me ou 
a un autre programme, 

- Tecriture dans une variable ou donnee dudit programme par le 
systeme ou par un autre programme, 

- la reception d'arguments k Tappel d'une routine dudit programme par 
le systeme ou par un autre programme, 

- r exploitation de la valeur de retour de Tappel par ledit programme 
d'une routine appartenant au systeme ou a un autre programme, 

- le rattrapage par ledit programme d'une exception levee durant 
rex6cution d'une routine appartenant au systeme ou ^ un autre 
programme, 

- la reception par ledit programme d'une interruption ou d'un signal 
value. 

Le systeme pourra disposer d'un mecanisme pour determiner si une valeur 
25 donnee est ime reference valide, les references licites memorisees etant 
restreintes aux seules references sur des donn^es considerees comme sensibles 
par le systeme. 

Les susdites verifications pourront consister a controler que les valeurs sont 
30 parmi les references licites sensibles que Ton a memorisees pour ce 
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programme ou bien sont des references determinees comme valides et portant 
sur des domiees qui ne sont pas sensibles. 

Avantageusement, le systeme pourra disposer d'lm mecanisme (dit de pare- 
5 feu) qui interdit a certains programmes certaines operations sur certaines 
donnees referencees. Dans ce cas, les donnees considerees comme sensibles 
pour le systeme pourront consister en des donnees pour lesquelles les 
operations ne sont pas interdites par le pare-feu. 

10 De m§me, le pare-feu pourra interdire a un programme certaines operations 
sur des donnees appartenant a d'autres programmes ou au systeme, excepte sur 
celles declarees comme partageables. 

Le systdme d'ex6cution de programmes mis en oeuvre par le proced6 selon 
15 r invention pourra etre base sur une machine virtuelle « Java Card » et dans ce 

cas : 



- le programme execute par le systeme pourra etre constitue par 
r ensemble du code qui se trouve dans xm « package » « Java Card », 

20 - le mecanisme de pare-feu pourra consister en celui du « Java Rimtime 
Environment » (JCRE), 

- les donnees declarees comme partageables (et done sensibles) pourront 
consister en les objets qui sont des instances de classes qui 
implementent I'interface « javacard.fi:amework.Shareable » lorsque 

25 ledit « package » appelle une m6thode d'un autre « package » ou du 

systeme (y compris la m^thode « getAppletShareablelnterfaceObject » 
du package « javacard.frameworkJCSystem »), 

- la lecture d'un champ statique public de type 
« javacard.fi:amework.Shareable » dans un autre « package » ou dans le 

30 systeme. 
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- le rattrapage d'un objet instance d'une classe provenant (heritant) de 
« java.lang.Throwable » et implementant « j avacard.framework. 
Shareable ». 

5 Dans le precede precedemment decrit, 1' ensemble des references licites (ou 
licites sensibles) memorisees pourra etre represents par une table. 

II pourra 8tre vide, gr^ce a un ramasse-miettes, des references devenues 
inactives (c'est-a-dire correspondant a des donnees effacees du programme ou 
10 inutilisables pour un acces futur dans la suite de T execution), ce ramasse- 
miettes pouvant etre conservatif. 

Les references pourront etre representees dans le systeme par des « handles » 
et des tables de pointeurs (ou de references), certaines de ces tables 6tant 
15 eventuellement reservSes aux references licites (ou licites sensibles). 

Les ensembles de references licites (ou licites sensibles) memorisees pourront 
etre representes par des vecteurs (ou matrices) de bits associes a certaines des 
tables de pointeurs (ou de references) oix un bit, k un index donne, represente 
20 la presence ou Tabsence de la reference correspondante dans lesdits 
ensembles. 

Les vecteurs de bits pourront etre eventuellement creux et representes a I'aide 
d'une sequence d' indices ou de longueurs correspondant aux etendues de bits 
25 positionnSs de la m§me maniere (soit a 1, soit a 0), 

De meme que la verification dynamique de la validite des references, le 
mecanisme mis en oeuvre par le procede selon T invention n'interdit pas la 
contrefa9on de references. Cependant, il interdit Tacces a des donnees via des 
30 references qui ne peuvent pas etre obtenues par des moyens licites. Or c'est ce 
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controle qui seul importe ; que la reference ait ete fabriquee de toute piece en 
pratique importe peu tant qu'elle est licite. 

Par exemple, si le programme construit un entier et tente de Tutiliser comme 
5 une reference, soit cet entier ne correspond pas a une reference presente dans 
Tensemble des references licites memorisees pour ce programme et T operation 
est rejetee, soit cet entier correspond k ime reference deja presente dans 
Tensemble des references licites memorisees pour ce programme et ne permet 
done de faire que des accds licites. L'attaque d'un programme malveillant 
10 cherchant a fabriquer une reference vers une donnee partageable devient ainsi 
ininteressante puisque le programme ne pourra acceder a cette donnee que s'il 
avait de toute fa9on pu obtenir cette meme reference auparavant, par des 
moyens licites. 

15 II est possible de perfectionner ce mecanisme de plusieurs manidres : 

- d'une part, on peut limiter les references a memoriser a celles qui 
importent pour la politique de securite du systeme et limiter le 
contrdle aux seules operations que Ton veut voir interdites quand 

20 elles portent sur des references illicites ; 

- d'autre part, suivant le mode de representation des references, on 
peut mettre en oeuvre des implementations plus ou moins efficaces 
des ensembles de references licites memorisees. 

25 Des perfectionnements, dont Tobjectif est de consommer moins d'espace 
memoire et moins de temps d'ex6cution, sont combinables et seront decrits ci- 
apres k titre d'exemples non limitatifs. 



La verification dynamique des references licites sensibles : 

30 
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L'acces aux donnees est parfois cloisonne au sein d'un meme programme. Par 
exemple, en « Java » comme en « Java Card », certains champs d'une classe 
peuvent Stre declares prives et ainsi n'6tre accessibles qu'^ partir des m^thodes 
de cette classe. Toutefois, ce contrdle d'accessibilite correspond souvent plus k 
5 des motivations de genie logiciel qu'a un souci de securite. Ce qui importe 
veritablement en « Java Card » est le cloisonnement entre les donnees de 
programmes differents car, en quelque sorte, les programmes « ne se font pas 
confiance entre eux ». En revanche, a Tint^rieur d'un meme programme, il 
importe peu de restreindre les acces possibles. Par exemple, meme si une 
10 reference vers une donn6e du programme est stockee dans un champ prive, et 
si ce meme programme fabrique de maniere quelconque un exemplaire de 
cette reference sans lire ce meme champ prive et Tutilise pour acceder a la 
donnee, la securite du programme et de ses donnees n'est pas mise en danger. 



15 Cette remarque permet de definir un premier perfectionnement du mecanisme 
de verification dynamique des references licites en restreignant les references 
memorisees et controlees. Ce perfectionnement est defini de la maniere 
suivante : 

- d'une part, on ne memorise au cours de Texecution que Tensemble 
20 des references a des donnees sensibles qu'obtient un programme par 

des moyens licites. C'est le contexte ou le type de systeme qui 
determine quelles sont les donnees que Ton peut considerer comme 
« sensibles ». Par exemple, dans le cas de « Java Card », on peut ne 
considerer comme sensibles pour un programme que les donnees qui 
25 appartiennent aux autres programmes. On peut exclure des donnees 

considerees comme sensibles les donnees publiques du systeme : 
tableaux globaux (« global arrays ») et objets points d' entree du 
JCRE (« JCRE Entry Point Objects »). En effet, bien qu'on ne puisse 
obtenir des references vers ces donnees que dans des circonstances 
30 particulieres (par exemple, retour d'appel de routine), Faeces a ces 

donnees est ouvert a tous. En pratique, les donnees sensibles peuvent 
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meme se reduire aux seules donnees explicitement declarees comme 
partageables, c'est-^-dire aux objets qui sont des instances de classes 
qui impl6mentent Tinterface « javacard.fi:amework,Shareable », car 
les autres donnees sont de toute fa9on protegees par le mecanisme de 
5 pare-feu de la JCVM. Dans ce dernier cas, on memorise dans 

I'ensemble des references licites sensibles d'un « package » toutes les 
references qui apparaissent dans les cas suivants : passage 
d'arguments de type « Shareable » lorsqu'une methode du 
« package » est appelee, valeur de retour de type « Shareable » 

10 lorsque le « package » appelle une methode d'un autre « package » 

ou du systeme (y compris la valeur de retour de la methode 
« getAppletShareablelnterfaceObject » du package 

« javacard.firameworkJCSystem »), lecture d'un champ statique de 
type « Shareable » dans un autre « package », et rattrapage d'une 

15 exception de type « Shareable » ; 

- d'autre part, on verifie, avant toute operation que Ton veut interdire si 
elle porte sur des valeurs qui ne sont pas des references licites, que la 
valeur est parmi les references licites sensibles que Ton a 
m6moris6es pour ce programme ou bien est une reference valide sur 

20 une donnee qui n'est pas sensible. II faut noter qu'il est indispensable 

de disposer egalement d'un mecanisme de verification de la validite 
des references (voir ci-dessus) afin de se premunir contre des 
attaques par contrefa9on d'une reference vers un faux descripteur de 
donnees. Dans le cas de la JCVM, si Ton ne considere comme 

25 sensible que les objets partageables, il suffit que Tinstruction 

« invokeinterface » verifie, lorsque qu'elle est appliquee h une 
reference vers un objet appartenant a un autre « package », que cette 
reference appartient bien a Tensemble des references licites sensibles 
associe au « package » appelant. 



30 
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Cette verification dynamique des references licites sensibles a Tavantage de 
consommer moins d'espace memoire, puisqu'on memorise moins de 
references, et moins de temps d'execution, puisqu'on verifie moins 
d'operations et que le test d'appartenance a Tensemble des references licites est 
5 plus rapide du fait de sa plus petite taille. 

Representation de Tensemble des references licites : 

Par ailleurs, les petits systemes embarques tels que les cartes a puce disposent 
10 de tres peu de memoire. II est done important sur de tels systemes de pouvoir 
representer Tensemble des references licites (ou licites sensibles) d'un 
programme de maniere compacte tout en permettant une verification 
dynamique rapide. 

15 La methode la plus directe pour representer Tensemble des references licites 
(ou licites sensibles) d'un programme est d'utiliser une table. Lors de 
rintroduction dans le programme d'une reference par un moyen licite, on 
Tajoute dans la table si elle n'y est pas deja presente. La verification qu'une 
reference est licite se fait par examen successif des entrees dans la table. 

20 

D'autres manieres standards en algorithmique pour representer des ensembles 
peuvent aussi Stre employees : listes, arbres, etc. Certaines representations des 
ensembles permettent notamment d'optimiser les operations d'ajout, de 
suppression et de test de presence d'un element dans un ensemble lorsqu'on 
25 connait a Tavance le nombre maximum (ou maximum probable) d'elements. 
On peut en effet alors dimensionner Tensemble selon ce nombre maximum et 
faire des acces plus ou moins directs aux elements. 

Nettoyage de Tensemble des references licites : 

30 
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D' autre part, il faut veiller a la coherence des references licites (ou licites 
sensibles) memoris6es en cas de suppression de donnees. 

En effet, en cours d' execution, des donnees devenues inutiles ou inaccessibles 
5 peuvent etre supprimees de la m^moire du systeme ou d'un programme. Une 
donnee devient inaccessible des lors que le programme ne contient plus de 
r6f6rence active sur cette donnee, c'est-a-dire encore susceptible d'6tre utilisee 
par le programme dans la suite de son execution. De telles donnees peuvent 
Stre effacees explicitement, par Tappel k une routine de liberation de m^moire, 
10 ou automatiquement, par im ramasse-miettes (« garbage collector »). 

Si une reference devient inactive dans un programme, Tensemble des 
references licites (ou licites sensibles) memorisees reste compatible avec la 
securite du systeme : le programme est de toute fa9on libre d'utiliser ou non 
15 les references dont il dispose, et Ton pent controler que toutes celles qu'il 
utilise sont bien licites. Un tel ensemble peut toutefois Stre nettoye des 
references inactives, afin de reduire son encombrement en memoire. Ce 
nettoyage devient meme imperatif si Tallocateur de donnees peut creer une 
nouvelle donnee associee k une reference dont la donnee a 6t6 supprimee. 

20 

Le nettoyage de Tensemble des references licites (ou licites sensibles) peut §tre 
effectue automatiquement, par un ramasse-miettes. II doit pour cela parcourir 
toutes les valeurs presentes dans le programme en cours d^execution afin de 
determiner les references encore actives. Toutes les references rencontrees lors 
25 de ce parcours sont marquees comme « encore en service » dans Tensemble 
des references licites du programme, A la fin de ce parcours, toutes les entrees 
non marquees peuvent Stre liberees : elles correspondent h des donnees 
auxquelles le programme a pu acceder dans le passe, mais sur lesquelles il n'a 
pas garde de reference (ou pas de reference utilisable). 



wo 2005/073827 



PCT/FR2004/003275 



Dans le cas ou des doimees peuvent ainsi Stre effacees, il n'est pas necessaire 
de dimensionner Tensemble des references licites selon le nombre de donndes 
referencees dans le systeme : on peut le sous-dimensionner et le d^barrasser 
regulierement, par exemjple lorsque Tensemble est plein, des elements qui ne 
5 sont plus utiles. Ainsi, il suffit de dimensionner Tensemble des references 
licites d'un programme au nombre de references simultanement actives lors de 
son execution, nombre qui est plus petit que le nombre de donnees ref6renc6es 
dans le systeme. 

10 Par ailleurs, dans le cas ou Ton ne salt pas decider avec certitude si une valeur 
represente ou non une reference, ce qui est le cas dans un systeme d'execution 
(y compris une machine virtuelle) qui ne conserve pas toutes les informations 
de type, on peut avoir recours a xm ramasse-miettes dit « conservatif ». Avec 
im tel ramasse-miettes, toute valeur susceptible d'etre une reference (par 

15 exemple un entier) est consideree comme telle par securite. Ce ramasse- 
miettes est dit conservatif car les valeurs prises h tort pour des references 
empechent le nettoyage de ces references ; en revanche, on est sur qu'aucune 
reference ne peut etre supprimee tant qu'elle est encore active. 

20 Representation des references licites par filtrage des tables de « handles » : 

Enfin, lorsque les references sont representees par des « handles », auxquels 
correspondent des index associes a ime ou plusieurs tables de pointeurs (ou de 
references) gerees par le systdme, Tensemble des references licites (ou licites 
25 sensibles) d'un programme peut 6tre represente de manidre plus compacte. 

On peut employer pour cela des vecteurs de bits de meme taille que les tables 
de pointeurs. Ces vecteurs sont interpretes comme des filtres sur les tables de 
pointeurs (ou de references) pour indiquer les references considerees comme 
30 pr^sentes dans Tensemble : un bit leve (egal a 1) ou non (egal a 0) a im index 
donne indique si la reference correspondante doit Stre consider6e ou non dans 
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Tensemble des . references licites (ou licites sensibles) du programme. L'ajout, 
la suppression et le test de pr6sence d'un element dans Tensemble est 
extremement rapide puisqu'il n'y a qu'un bit a positionner ou tester. En 
attribuant des numeros aux programmes, on peut aussi regrouper ces vecteurs 
5 de bits en une matrice de bits dont une des coordonnees est indexee par le 
numero du programme. 

S'il y a beaucoup de references dans le systeme et si tres peu sont k consid^rer 
comme licites (ou licites sensibles) pour chacun des programmes, cette 
10 matrice de bits peut finalement s'averer moins compacte qu'une representation 
par simple table de references explicites. Dans ce cas^ on peut essayer 
d' employer une representation sous forme de vecteur creux (ou de matrice 
creuse), par exemple une sequence d' indices ou de longueurs correspondant 
aux etendues de bits positionnes de la mSme manidre (soit a 1, soit a 0). 

15 

On peut aussi exploiter des tables diff6rentes pour memoriser d'une part les 
« handles » qui sont des references licites (ou licites sensibles) et d'autres part 
les autres references. Les vecteurs de bits deviennent ainsi beaucoup moins 
longs et beaucoup plus denses. 
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Revendications 

1. Precede de controle d'accds a des doiinees manipulees par r6f6rences 
dans un systeme d'ex6cution de programmes (y compris processus et tSches), 

5 caracterise en ce que, lors de Texecution dun programme, il comprend les 
etapes suivantes : 

la memorisation par le systeme de Tensemble des references qu'obtient le 
programme par des moyens consideres comme licites ; 
avant toute operation que Ton veut interdire si elle porte sur des valeurs 
10 qui ne sont pas des references licites, la verification par le systdme que ces 

valeurs sont parmi les references licites que Ton a memorisees pour ce 
programme, et Tacceptation ou le rejet de Toperation en consequence. 

2. Proc6de selon la revendication 1, 

15 caract6ris6 en ce que les references sont des pointeurs et/ou des « handles ». 

3. Procede selon la revendication 1, 

caracterise en ce que les moyens licites pour un programme d'obtenir des 
valeurs references comprennent au moins Tune des operations suivantes : 
20 - la lecture d'une variable ou d'lme donnee appartenant au systeme ou a un 
autre programme, 

recriture dans une variable ou donnee dudit programme par le systeme ou 
par un autre programme, 

la reception d'arguments a Tappel d'une routine dudit programme par le 

25 systeme ou par un autre programme, 

r exploitation de la valeur de retour de Tappel par ledit programme d'une 
routine appartenant au systeme ou a un autre programme, 
le rattrapage par ledit programme d'une exception levee durant Texecution 
d'une routine appartenant au systeme ou a un autre programme, 

30 - la reception par ledit programme d'une interruption ou d*un signal value. 
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4. Procede selon la revendication 1, 
caracterise en ce que : 

le systeme comprend un mecanisme qui determine si une valeur donnee 
est une reference valide, et/ou 
5 - les references licites memorisees sont restreintes aux seules ref6rences sur 
des donnees considerees comme sensibles pour le systeme, et/ou 
lesdites verifications contr61ent que les valeurs sont parmi les references 
licites sensibles que Ton a m6morisees pour ce programme ou bien sont 
des references d6temiinees comme valides et portant sur des donnees qui 
10 ne sont pas sensibles. 

5. Procede selon la revendication 4, 

caracterise en ce que le systeme comprend un pare-feu qui interdit a certains 
programmes certaines operations sur certaines donnees r^f^rencees, les 
15 donnees considerees comme sensibles pour le systeme 6tant celles pour 
lesquelles les operations ne sont pas interdites par le pare-feu. 

6. Procede selon la revendication 5, 

caracterise en ce que le pare-feu interdit a un programme certaines operations 
20 sur des donnees appartenant k d'autres programmes, excepts sur celles 
declarees comme partageables. 

7. Procede selon la revendication 6, 

caracterise en ce que le systeme est base sur une machine virtuelle « Java 
25 Card » et en ce que : 

im programme est constitue par T ensemble du code qui se trouve dans un 
« package Java Card » ; 

le pare-feu est celui du « Java Card Runtime Environment » (JCRE) ; 
les donnees declarees comme partageables (et done sensibles) sont les 
30 objets qui sont instances de classes qui implementent Tinterface 

«javacard.framework.Shareable » ainsi que, eventuellement, les objets a 
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usage public du systeme : tableaux globairx (« global arrays ») et objets 
points d'entree du JCRE (« JCRE Entry Point Objects »). 

8. Procede selon la revendication 7, 

5 caracterise en ce que le systeme memorise dans les ensembles de references 
licites sensibles associes a un « package » toutes les references qui 
apparaissent dans les cas suivants : 

la reception d'arguments de type « javacard.framework.Shareable » 
lorsqu'une methode dudit package est appel^e par un autre « package » ou 
10 par le systeme, 

la valeur de retour de type « javacard.framework.Shareable » lorsque ledit 
« package » appelle une methode d'un autre « package » ou du systeme (y 
compris la methode « getAppletShareablelnterfaceObject » du package 
« javacard.frameworkJCSystem »), 
15 - la lecture d'un champ statique public de type 
« javacard.framework.Shareable » dans un autre package ou dans le 
systeme, 

le rattrapage d'un objet instance d'une classe provenant (heritant) de 
«java.lang.Throwable» et implementant «javacard.framework.Shareable». 

20 

9. Procede selon Tune des revendications 1 et 4, 

caracterise en ce que Tensemble des references licites (ou licites sensibles) 
memorisees est represents par une table. 

25 10. Proc6de selon Tune des revendications 1 et 4, 

caracteris6 en ce que Tensemble des references licites (ou licites sensibles) 
m6moris6es est vide, grSce k un ramasse-miettes, 6ventuellement conservatif, 
des references devenues inactives. 
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11. Precede selon Tune des revendications 1 et 4, 
caracterise en ce que : 

- les ref6rences sont representees dans le systoe par des « handles » et des 
tables de pointeurs (ou de references), 

5 - certaines desdites tables sont eventuellement reservees aux references 
licites (ou licites sensibles), 

- les ensembles de references licites (ou licites sensibles) memorisees sont 
representes par des vecteurs (ou matrices) de bits associes k certaines des 
tables de pointeurs (ou de references), ou un bit k un index donn^ 

10 represente la presence ou Tabsence de la reference correspondante dans 

lesdits ensembles, 

lesdits vecteurs de bits sont eventuellement creux et representes a Taide 
d'une sequence d'indices ou de longueurs correspondant aux etendues de 
bits positionnes de la meme manidre. 



INTERNATIONAL SEARCH REPORT 



Internati^lPApplication No 

PCT/FR2004/003275 



A. CLASSIFICATION OF SUBJECT MATTER 

IPC 7 606F1/00 



According to International Patent Classification (IPC) or to both national classification and IPC 



B. FIELDS SEARCHED 



Minimum documentation searched (classification system followed by classification symbols) 

IPC 7 G06F 



Documentation searched other than minimum documentation to the extent that such documents are Included In the fields searched 



Electronic data base consulted during the International search (name of data base and, where practical, search terms used) 

EPO-Internal , PAJ 



C. DOCUMENTS CONSIDERED TO BE RELEVANT 



Category Citation of document, with indication, where appropriate, of the relevant passages 



Relevant to claim No. 



wo 00/45262 A (SUN MICROSYSTEMS INC) 
3 August 2000 (2000-08-03) 
the whol^ document 



US 6 658 573 Bl (BISCHOF JOERG ET AL) 
2 December 2003 (2003-12-02) 
the whole document 



1-11 



1-11 



□ 



Further documents are listed in the continuation of box C. 



Patent family members are listed in annex. 



° Special categories of cited documents : 

'A' document defining the general state of the art which Is not 
considered to be of particular relevance 

'E' earlier document but published on or after the international 
filing date 

"L" document which may throw doubts on priority clalm(s) or 
which is cited to establish the publication date of another 
citation or other special reason (as specified) 

'O' document referring to an oral disclosure, use, exhibition or 
other means 

'P' document published prior to the International filing date but 
later than the priority date claimed 



"T" later document published after the international filing date 
or priority date and not in conflict with the application but 
cited to understand the principle ortheoiy underlying the 

invention 

"X' document of particular relevance; the claimed invention 
cannot be considered novel or cannot be considered to 
Involve an inventive step when the document is taken alone 

■Y" document of particular relevance; the claimed invention 

cannot be considered to involve an inventive step when the 
document is combined with one or more other such docu- 
ments, such combination being obvious to a person skilled 
in the art. 

document member of the same patent family 



Date of the actual completion of the international search 



6 May 2005 



Date of mailing of the International search report 



25/05/2005 



Name and mailing address of the ISA 

European Patent Office, P.B, 5818 Patentlaan 2 
NL~2280 HV Rijswijk 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl, 

Fax: (+31-70) 340-3016 



Authorized officer 



Meis, M 



Form PCT/ISA/210 (second sheet) (January 2004) 



INTERNATIONAL SEARCH REPORT 

InTormation on patent family members 



^ntemad|||P^^ No 

PCT/FR2004/003275 



Patent documGnt 


Publication 




Patent family 




Publication 


cited In search report 


date 




member(s) 




date 


WO 0045262 A 


03-08-2000 


AT 


269558 


T 


15-07-2004 






AU ' 


763958 


B2 


07-Oo-ZOOo 






AU 


yi "1 £^t~^ r\r\ 

4165700 


A 

A 


1 o no onnn 






CN 


1338071 


A 

A 


0*7 AO OAAO 






DE 


1190316 


T 1 

Tl 


AZT AO OAAO 

06— 03— ^Uuo 






DE 


60011615 


Dl 


22-07-2004 






EP 


1190316 


A2 


27-03-2002 






EP 


1/1/1 ccnrk 




1 1 no or\r\A 






JP 


2003518279 


T 

T 


AO A/T OAAO 

03-0o-200o 






WO 


0045262 


A2 


AO AO OAAA 

03-08-2000 


US 6658573 Bl 


02-12-2003 


WO 


9832073 


A 1 

Al 


OO A*7 1AAO 

23-07-1998 






DE 


69706440 


Dl 


04-10-2001 






DE 


69706440 


T2 


16-05-2002 






EP 


0953172 


Al 


03-11-1999 






JP 


3381927 


B2 


04-03-2003 






JP 


2000508104 


T 


27-06-2000 



Form PCT/ISA/210 {patent family annex) (January 2004) 



RAPPORT DE RECHERCHE INTERNATIONALE 



Demam 



rnattonate No 



PCT/FR2004/003275 



A. CLASSEMENT DE L'OBJET DE LA DEMANDE 

CIB 7 G06F1/00 



Seion la classification internaHonale des brevets (GIB) ou k lafois selon la-classification nationale et la CIB 



B. DOMAINES SUR LESQUELS LA RECHERCHE A PORTE 



Documentation minimale consult6e (systeme de classification suivi des symboles de classemenl) 

CIB 7 G06F 



Documentation consult^e autre que la documentation minimale dans la mesure oD ces documents relevent des domaines sur lesquels a portd la reclierclie 



Base de donn^es ^lectronique consult6e au cours de la recherche Internationale (nom de la base de donn^es, et si realisable, termes de recherche utilises) 

EPO-Internal , PAJ 



C. DOCUMENTS CONSIDERES COMME PERTINENTS 



Cat^gorie " Ideniiflcation des documents cit^s, avec, le cas 6ch6ant, I'indication des passages pertinents 



no. des revendtcations vis6es 



wo 00/45262 A (SUN MICROSYSTEMS INC) 
3 aoQt 2000 (2000-08-03) 
le document en entier 



US 6 658 573 Bl (BISCHOF JOERG 
2 decembre 2003 (2003-12-02) 
le document en entier 



ET AL) 



1-11 



1-11 



I j Voir la suite du cadre 0 pour la fin de la liste des documents 



Les documents de families de brevets sont indiques en annexe 



' Categories sp6ciales de documents cit6s: 

'A" document definlssant I'^tat general de la technique, non 
consid6r6 comme partlcullferement pertinent 

'E' document ant6rieur, mais public ^ la date de d6p6t international 
ou apres cette date 

'L' document pouvant jeter un doute sur une revendication de 
priority ou cite pour determiner la date de publication d'une 
autre citation ou pour une raison spdciale (telle quMndiquSe) 

'C document se r^fSrant h une divulgation orale. k un usage, k 
une exposition ou tous autres moyens 

'P' document public avant la date de d^pdt international, mais 
posterleurement k la date de priority revendiquSe 



■T" document ult6rleur public apr^s la date de d6p6t International ou la 
date de priority et n'appartenenant pas a I'etat de la 
technique pertinent, mais cite pour comprendre le principe 
ou la theorie constltuant la base de invention 

■X* document particuli6rement pertinent; I'inven tion revendlqu6e ne peut 
6tre conslder6e comme nouvelle ou comme impllquant une activity 
inventive par rapport au document consider^ isol6ment 

■V document particuli^rement pertinent; Pinven tion revendiqu§e " 
ne peut 6tre consfderSe comme Impiiquant une activity inventive 
iorsque le document est associe k un ou plusleurs autres 
documents de mSme nature, cette combinaison etant evldente 
pour une personne du metier 

*&* document qui fait partle de la m§me famllle de brevets 



Date k laquelle la recherche Internationale a ete effectivement achevee 



6 mai 2005 



Date d'expeditlon du present rapport de recherche intematlonale 



25/05/2005 



Nom et adresse postale de I'administratlon chargee de la recherche Internationale 
Office Europeen des Brevets, P.B. 5818 Patentlaan 2 
NL--2280 HV RIJswijl< 
Tel. (+31-70) 340-2040, Tx. 31 651 epo nl« 
Fax: (+31-70) 340-3016 



Fonctlonnaire autorise 



Me1s, M 



Formulaire PCT/ISA/210 (deuxiSme feuille) (Janvier 2004) 



RAPPORT DE RECHERCHE INTERNATIONALE 

Renseignements relatlfs aux membres de families de brevets 



Deinand||Pemationale No 

PCT/FR2004/003275 



Document brevet cite 
au rapport de recherche 



Date de 
publication 



l^embre(s) de la 
famine de brevet(s)_ 



Dale de 
publication 



WO 0045262 



03-08-2000 



AT 269558 T 

AU 763958 B2 

AU 4165700 A 

CN 1338071 A 

DE 1190316 Tl 

DE 60011615 Dl 

EP 1190316 A2 

EP 1445699 A2 

JP 2003518279 T 

WO 0045262 A2 



US 6658573 



Bl 



02-12-2003 



WO 9832073 Al 

DE 69706440 Dl 

DE 69706440 T2 

EP 0953172 Al 

JP 3381927 B2 

JP 2000508104 T 



15-07- 
07-08- 
18-08- 
27-02- 
06-03- 
22-07- 
27-03- 
11-08- 
03-06- 
03-08- 



2004 
2003 
2000 
2002 
2003 
2004 
2002 
2004 
2003 
2000 



23-07-1998 
04-10-2001 

16-05-2002 

03- 11-1999 

04- 03-2003 
27-06-2000 



Formulaire PCT/ISA/210 (annexe famiUes de brevets) (Janvier 2004) 



